Contrôle MQTT planifié

astuce

Le contrôle MQTT programmé est destiné aux messages programmés à l'avance. Pour le contrôle en direct, voir Contrôle MQTT en direct à la place.

Ce guide vous aidera à configurer MQTT sur votre SmartgridOne Controller pour contrôler et surveiller à distance les installations de batteries et de panneaux solaires.

Ce dont vous avez besoin

1. SmartgridOne Controller avec connectivité Internet.
2. Identifiants MQTT : Cela peut être demandé en envoyant un e-mail à support@eniris.be.
3. Environnement de développement Python (ou tout autre client MQTT). Ce guide utilise un exemple basique écrit en Python pour vous aider à démarrer avec MQTT et l'envoi de commandes. Nous recommandons d'utiliser Python pour sa facilité d'utilisation, mais tout autre client MQTT est également pris en charge.

Informations supplémentaires

MQTT est un protocole de communication rapide sur Internet. Il s'agit d'un système de messagerie publish/subscribe, qui permet une connexion directe entre votre machine et le SmartgridOne Controller. Vos actifs sont classés en groupes solaires, batteries, VE et CVC. Pour le moment, cette intégration permet un contrôle par groupe, et non par appareil.

Configuration initiale (Point de départ pour les nouveaux utilisateurs)

J'ai un SmartgridOne Controller que j'aimerais configurer pour le contrôle à distance via MQTT.

1. Vérifiez votre réseau

Assurez-vous que votre réseau permet le trafic mqtt sur le port 1883. Vous pouvez le faire en utilisant la commande :

nc -zv mqtt.eniris.be 1883

Lorsque cette commande n'est pas disponible, vous pouvez alternativement télécharger et exécuter ce code python.

En cas de doute, consultez votre ingénieur réseau ou utilisez temporairement le point d'accès 4G/5G de votre téléphone lorsque des erreurs de connexion se produisent.

remarque

Lorsque le port 1883 n'est pas accessible depuis votre réseau, nous offrons une option de secours sur le port 80. Cela peut être configuré dans votre client MQTT à une étape ultérieure de ce manuel.

2. Ajoutez vos appareils

Connectez-vous à l'interface de mise en service et assurez-vous que les appareils sont ajoutés au SmartgridOne Controller.

3. Ajoutez le signal externe MQTT

4. Activez le signal à distance MQTT

Sélectionnez tous les appareils que vous souhaitez inclure dans le contrôle à distance MQTT.

5. Le signal à distance est ajouté

L'interface de contrôle à distance MQTT a maintenant été activée sur le SmartgridOne Controller.

Nous sommes maintenant prêts à envoyer quelques commandes de base en utilisant un exemple simple. La colonne Statut vous indique si une commande est active.

Script de démonstration Python

Un bon point de départ serait de tester votre intégration nouvellement configurée avec un exemple simple.

Ce code de test effectue une tâche simple consistant à envoyer en continu le calendrier suivant :

• Batterie : Charger à 5 kW pendant 15 minutes dans 10 minutes
• Solaire : Régler la puissance à 0 kW pendant une heure dans 30 minutes

Le SmartgridOne Controller répond avec un message d'accusé de réception contenant l'identifiant unique du calendrier, ou un message d'erreur.

Nous récupérons ensuite le calendrier suivant pour les deux types d'appareils, confirmant que la commande a été réussie.

Veuillez télécharger le fichier ci-dessous dans votre IDE Python préféré. Remplissez votre numéro de série et vos identifiants MQTT et exécutez le script :

Lorsque cela réussit, vous pouvez continuer à envoyer d'autres types de messages. Tous les messages sont décrits ci-dessous.

Documentation MQTT pour l'envoi de commandes

Cette section détaille le format de message MQTT et les exigences de charge utile pour configurer le contrôle programmé des appareils au sein du réseau du SmartgridOne Controller.

Sujets MQTT

• Sujet d'abonnement : standard1/rp_one_s/remoteScheduleMetrics/<controller SN>
• Sujet de retour : standard1/outbound/remoteScheduleMetrics/feedback/<controller SN>

Où <controller SN> doit être remplacé par le numéro de série réel du SmartgridOne Controller que vous souhaitez contrôler.

Types de messages MQTT

1. Définir un calendrier (set_schedule)

Crée un nouveau calendrier pour un type d'appareil.

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": <Unix Timestamp>,
    "message_type": "set_schedule",
    "fields": {
        "device_type": "<Device Type>",
        "node_id": "<Node ID>" (Optionnel),
        "start_time": <Unix Timestamp>,
        "end_time": <Unix Timestamp>,
        "policy": "<Policy>",
        "power_setpoint_w": <Setpoint en watts>,
        "replace_overlap": <True/False> (Optionnel) (défaut=False),
    }
}

Réponse (Succès) :

{
    "requestTime": <Unix Timestamp>,
    "time": <Unix Timestamp>,
    "siteNodeId": "<Controller SN>_site_0",
    "data": {
        "message_type": "set_schedule_ack",
        "state": {
            "schedule_id": <Schedule ID>,
            "deleted_ids": <Schedule IDs supprimés si replace_overlap=True>
        },
        "responseCode": 0
    }
}

2. Obtenir le calendrier (get_schedule)

Récupère un calendrier spécifique par ID.

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": <Unix Timestamp>,
    "message_type": "get_schedule",
    "fields": {
        "id": <Schedule ID>
    }
}

Réponse :

{
    "requestTime": <Unix Timestamp>,
    "time": <Unix Timestamp>,
    "siteNodeId": "<Controller SN>_site_0",
    "data": {
        "message_type": "get_schedule_ack",
        "state": <Schedule>,
        "responseCode": 0
    }
}

3. Obtenir le calendrier actif (get_active_schedule)

Récupère le calendrier actif actuel pour un type d'appareil.

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": <Unix Timestamp>,
    "message_type": "get_active_schedule",
    "fields": {
        "device_type": "<Device Type>",
        "node_id": "<Node ID>" (Optionnel),
    }
}

Réponse (Succès) :

{
    "requestTime": <Unix Timestamp>,
    "time": <Unix Timestamp>,
    "siteNodeId": "<Controller SN>_site_0",
    "data": {
        "message_type": "get_active_schedule_ack",
        "state": <Schedule>,
        "responseCode": 0
    }
}

4. Obtenir le prochain calendrier (get_next_schedule)

Récupère le prochain calendrier à venir pour un type d'appareil.

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": <Unix Timestamp>,
    "message_type": "get_next_schedule", 
    "fields": {
        "device_type": "<Device Type>",
        "node_id": "<Node ID>" (Optionnel),
    }
}

Réponse (Succès) :

{
    "requestTime": <Unix Timestamp>,
    "time": <Unix Timestamp>,
    "siteNodeId": "<Controller SN>_site_0",
    "data": {
        "message_type": "get_next_schedule_ack",
        "state": <Schedule>,
        "responseCode": 0
    }
}

5. Obtenir les calendriers (get_schedules)

Récupère tous les calendriers pour une date spécifique.

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": <Unix Timestamp>,
    "message_type": "get_schedules",
    "fields": {
        "date": "<Date String of Format dd/mm/yyyy>"
    }
}

Response (Success):

{
    "requestTime": <Unix Timestamp>,
    "time": <Unix Timestamp>,
    "siteNodeId": "<Controller SN>_site_0",
    "data": {
        "message_type": "get_schedules_ack",
        "state": {
            "schedules": [<Schedule>, ...]
        },
        "responseCode": 0
    }
}

6. Obtenir les horaires futurs (get_future_schedules)

Récupère tous les horaires futurs.

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": <Unix Timestamp>,
    "message_type": "get_future_schedules",
    "fields": {}
}

Response (Success):

{
    "requestTime": <Unix Timestamp>,
    "time": <Unix Timestamp>,
    "siteNodeId": "<Controller SN>_site_0",
    "data": {
        "message_type": "get_future_schedules_ack",
        "state": {
            "schedules": [<Schedule>, ...]
        },
        "responseCode": 0
    }
}

7. Supprimer un horaire (remove_schedule)

Supprime un horaire spécifique par ID.

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": <Unix Timestamp>,
    "message_type": "remove_schedule",
    "fields": {
        "id": <Schedule ID>
    }
}

Response (Success):

{
    "requestTime": <Unix Timestamp>,
    "time": <Unix Timestamp>,
    "siteNodeId": "<Controller SN>_site_0",
    "data": {
        "message_type": "remove_schedule_ack",
        "state": "Horaire <Schedule ID> supprimé avec succès",
        "responseCode": 0
    }
}

8. Obtenir les retours de site (get_feedback)

Récupère des retours détaillés sur l'état du système.

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": <Unix Timestamp>,
    "message_type": "get_feedback",
    "fields": {}
}

Response (Success):

Structure de la charge utile des retours

Format de réponse standard pour les horaires

{
    "id": <Schedule ID>,
    "device_type": "<Device Type>",
    "node_id": "<Node ID>" (Optionnel),
    "start_time": <Unix Timestamp>,
    "end_time": <Unix Timestamp>,
    "policy": "<Schedule Policy>",
    "power_setpoint_w": <Setpoint en watts>,
    "created_at": <Unix Timestamp>
}

Types de composants et politiques

Pour plus de détails sur les composants disponibles et les politiques pouvant être programmées, référez-vous à la section Composants et politiques MQTT dans la documentation sur le contrôle MQTT en direct.

Des horaires spécifiques aux appareils peuvent être envoyés en utilisant le champ optionnel node_id, se référant à l'ID du nœud de l'appareil contrôlable.

Gestion des erreurs

Tous les messages peuvent retourner une réponse d'erreur avec responseCode: 1 lorsqu'une erreur se produit :

{
    "requestTime": <Unix Timestamp>,
    "time": <Unix Timestamp>,
    "siteNodeId": "<Controller SN>_site_0",
    "data": {
        "message_type": "<Message Type>_ack",
        "error": <Error Body>,
        "responseCode": 1
    }
}

Lorsque se produit une erreur non liée, le type de message sera (general_error).

Les erreurs courantes incluent :

• Chevauchement d'horaires avec des horaires existants
• Plage horaire invalide
• Type d'appareil non trouvé
• Identifiant d'horaire non trouvé
• Politique invalide pour le type d'appareil

Règles de gestion des horaires

1. Règles de chevauchement
   • Les horaires ne peuvent pas se chevaucher pour le même type d'appareil.
   • Les horaires ne peuvent pas se chevaucher pour le même appareil.
   • Les horaires pour le même appareil et le même type d'appareil ne peuvent pas se chevaucher.
   • Les horaires existants et se chevauchant seront supprimés si la variable replace_overlap est définie sur True lors de la création d'un nouvel horaire.
2. Chaque horaire doit avoir :
   • Un type d'appareil valide
   • Une heure de début (timestamp Unix)
   • Une heure de fin (timestamp Unix)
   • Une politique (correspondant aux politiques disponibles pour le type d'appareil)
   • Un point de consigne de puissance (pour les politiques qui l'exigent)
3. L'heure de début doit être avant l'heure de fin.
4. L'heure de début doit être d'au moins cinq minutes dans le futur.
5. Les horaires ne peuvent être supprimés que s'ils commencent au moins cinq minutes dans le futur.
6. Les horaires peuvent être définis pour différents types d'appareils de manière indépendante.
7. Le système applique automatiquement la politique appropriée lorsqu'un horaire devient actif.